![\"\"](\"https:\/\/temp_new.vmenginelab.com\/wp-content\/uploads\/2012\/07\/cloud1.jpg\" "\\"Tormenta")
<\/p>\n<\/p>\n
Me parece muy gracioso ver en la red c\u00f3mo la gente habla constantemente y a menudo de forma inapropiada sobre la computaci\u00f3n en la nube, tanto positiva como negativamente. Todo el mundo \u00abdispara\u00bb su propia opini\u00f3n llam\u00e1ndose a s\u00ed mismo un experto en esto o aquello.<\/p>\n
Como sugiere el t\u00edtulo, este es un nuevo evento \u00abdesastroso\u00bb para la computaci\u00f3n en la nube. Y siento que es mi deber analizar el caso y responder a todos aquellos que solo han sido capaces de demonizar el \u00abcloud computing\u00bb como si fuera algo que se pueda se\u00f1alar.<\/p>\n
Les recuerdo a la mayor\u00eda que la computaci\u00f3n en la nube es un paradigma no una tecnolog\u00eda, les recuerdo que puede ser p\u00fablica y privada, para aquellos que la han olvidado o nunca han tenido la oportunidad de leer una definici\u00f3n oficial.<\/p>\n
Vayamos a lo que sucedi\u00f3 esta vez<\/strong>, al menos hasta donde sabemos.<\/p>\n Una tormenta muy fuerte<\/a> azot\u00f3 Estados Unidos el 30 de junio en el \u00e1rea de Virginia, causando al menos 12 muertes, qui\u00e9n sabe cu\u00e1ntos heridos, cu\u00e1ntos se quedaron sin hogar. Tambi\u00e9n se sabe que 2 millones de personas en toda la zona llevan mucho tiempo sin electricidad, y los t\u00e9cnicos se movilizaron de inmediato para tratar de restablecer la energ\u00eda lo m\u00e1s r\u00e1pido posible, con el fin de evitar que el calor r\u00e9cord en esa zona aumente el n\u00famero de muertes debido al mal funcionamiento de los aires acondicionados.<\/p>\n En Virginia existen los centros de datos<\/strong> de Amazon Web Services, esta es la regi\u00f3n hist\u00f3rica de AWS, la primera y tambi\u00e9n la \u00abpor defecto\u00bb<\/strong> de las APIs de gesti\u00f3n, es decir, si el cliente no cambia de regi\u00f3n siempre y \u00fanicamente utilizar\u00e1 los recursos de esta zona (basta con a\u00f1adir –region en el caso de la API Tool o hacer una set_region si usamos el SDK de php o quiz\u00e1s m\u00e1s f\u00e1cilmente con la Management Console), mientras que AWS se distribuye por todo el mundo (EE. UU., UE, ASIA, Jap\u00f3n, Am\u00e9rica del Sur) con muchos centros de datos.<\/p>\n Uno de estos centros de datos se ha quedado sin energ\u00eda, seg\u00fan Amazon<\/a>. (porque AWS hace p\u00fablico el estado de todos sus servicios en todas las regiones).<\/p>\n Sin embargo, muchos de los servicios de muchos clientes estaban presentes en esta regi\u00f3n y se encontraban fuera de l\u00ednea de un momento a otro. El caso caus\u00f3 sensaci\u00f3n porque en esta ocasi\u00f3n cayeron dos grandes portales sociales muy de moda, Instagram y Pinterest<\/strong> (tambi\u00e9n NetFlix), que permanecieron desconectados durante unas horas.<\/p>\n Pero me pregunto cu\u00e1ntos otros centros de datos menos conocidos con alojamiento de estilo antiguo han corrido la misma suerte.<\/p>\n Fue un evento extremo (probablemente por la forma en que va el clima de nuestro planeta, no ser\u00e1 el \u00faltimo),<\/p>\n AWS es el primer y m\u00e1s grande proveedor de nube, el m\u00e1s extendido, el m\u00e1s utilizado, el que tiene mayor presencia de sitios y portales con un tr\u00e1fico considerable, por lo tanto, es m\u00e1s probable que sea notado en la red por una amplia audiencia, digamos que est\u00e1 muy bajo escrutinio.<\/p>\n El 21 de abril de 2011 la misma regi\u00f3n<\/a> se vio comprometida por un error humano y en mi opini\u00f3n en este evento radica el verdadero problema al que se tienen que enfrentar las grandes infraestructuras llenas de datos en continuo aumento, el 7 de agosto en cambio los centros de datos irlandeses de AWS y Microsoft<\/a> se vieron comprometidos por una tormenta el\u00e9ctrica, en este caso parece que los CC estaban equipados con los mismos sistemas autom\u00e1ticos de respaldo de electricidad, un sistema evidentemente soplado debido a la sobretensi\u00f3n del rayo que ca\u00eda cerca.<\/p>\n Consideremos los dos casos originados en problemas clim\u00e1ticos extremos sin jugar demasiado con los s\u00edmbolos entre nubes y tormentas, como han hecho muchos columnistas.<\/p>\n Estamos tratando con centros de datos que han tenido problemas relacionados con los sistemas de respaldo de energ\u00eda y aqu\u00ed una breve descripci\u00f3n de c\u00f3mo funcionan los sistemas de respaldo de energ\u00eda de un CC est\u00e1 en orden. Un DC generalmente recibe energ\u00eda el\u00e9ctrica de un proveedor de energ\u00eda, esta va directamente al UPS (b\u00e1sicamente paquetes de bater\u00edas), luego de ah\u00ed pasa a las salas de servidores llenas de racks donde se encuentran los equipos de red, los servidores y el almacenamiento.<\/p>\n Un peque\u00f1o par\u00e9ntesis de GreenIT.<\/strong> Alrededor del 30% de la energ\u00eda se pierde en la transici\u00f3n de corriente alterna a corriente continua (UPS) y de corriente continua a corriente alterna a corriente alterna a corriente alterna, mientras que cada dispositivo convierte internamente la energ\u00eda el\u00e9ctrica en corriente continua. Este es uno de los varios puntos que hemos planteado en nuestro proyecto Make The Cloud Green<\/a>.<\/p>\n Por lo tanto, existen sistemas totalmente autom\u00e1ticos y confiables que intervienen estabilizando la electricidad a las salas de servidores, es decir, si no hay energ\u00eda en la fuente, el equipo la toma de los grupos UPS. Obviamente, estos est\u00e1n calibrados para soportar la carga completa unas pocas decenas de minutos, por lo que cada CC que se precie es alimentado por m\u00e1s de un grupo de generadores que siempre entran en funcionamiento autom\u00e1ticamente si el cuerpo de energ\u00eda ya no suministra energ\u00eda. Por lo general, estas unidades, generalmente compuestas por motores di\u00e9sel, tardan muy pocos minutos en arrancar, por lo que el funcionamiento de un CC debe estar garantizado durante muchas horas, es decir, hasta el final del combustible.<\/p>\n Otro par\u00e9ntesis de GreenIT<\/strong>: este caso de un banco alimentado \u00edntegramente por pilas de combustible<\/a>, es decir, fuera de la red<\/p>\n En general, todos estos dispositivos, que pueden llegar a entrar en funcionamiento, requieren de una monitorizaci\u00f3n peri\u00f3dica, mantenimiento y pruebas funcionales que dan lugar a simulaciones programadas de eventos catastr\u00f3ficos. Por lo tanto es un error hablar de Cloud Computing Outage<\/strong> , tenemos que centrarnos en el hecho de que los DCs han sido mal dise\u00f1ados, o no han sido mantenidos o simulados adecuadamente.<\/p>\n O tal vez se deber\u00eda pedir a AWS que haga p\u00fablicas las pruebas y los resultados que se hacen a todos los equipos circundantes de los DC, o m\u00e1s bien crear nuevos est\u00e1ndares, nuevas regulaciones relacionadas con la construcci\u00f3n de los DC, hacerlos energ\u00e9ticamente separados de la red, m\u00e1s seguros frente a eventos atmosf\u00e9ricos, por ejemplo veamos este centro de datos<\/a> construido en Estocolmo en un antiguo b\u00fanker nuclear. Otro par\u00e9ntesis de GreenIT<\/strong> ser\u00eda calentar las ciudades adyacentes con el calor emitido por los sistemas en lugar de desperdiciar m\u00e1s energ\u00eda para enfriar los sistemas y m\u00e1s para calentar los hogares. (alguien ya lo hace)<\/p>\n Ahora vayamos a lo que subestimaron los clientes que se encontraban fuera de l\u00ednea. AWS proporciona<\/strong> herramientas de computaci\u00f3n en la nube de grado IaaS, proporciona varios centros de datos y proporciona orientaci\u00f3n<\/strong> <\/a>sobre c\u00f3mo implementar sus propias arquitecturas, al tiempo que hace hincapi\u00e9 en el uso de varios centros de datos para aplicaciones cr\u00edticas para el negocio. Significa que un Instagram que ha recibido millones de d\u00f3lares de inversi\u00f3n, que no sabe c\u00f3mo dise\u00f1ar la soluci\u00f3n apoy\u00e1ndose en m\u00e1s de un centro de datos, est\u00e1 condenado, no la computaci\u00f3n en la nube en s\u00ed, ni AWS por c\u00f3mo se ha dise\u00f1ado la arquitectura SW de Instagram.<\/p>\n AWS proporciona una serie de servicios sobre los que garantiza Fault Tolerance y High Availability y son S3, SimpleDB, Simple Queue Service, Elastic Load Balancing, Elastic IP y tambi\u00e9n dir\u00eda Route53 y sobre los que puedes construir tus propios servicios de Alta Disponibilidad, como ya han hecho muchos otros clientes m\u00e1s inteligentes.<\/p>\n Por otro lado, ser\u00eda muy indecoroso ver a un Proveedor de Nube P\u00fablica PaaS y sobre todo SaaS con problemas de Alta Disponibilidad, como sucedi\u00f3 hace alg\u00fan tiempo por ejemplo con Gmail de Google.<\/p>\nResponsabilidades de software del cliente<\/h3>\n